[The introduction of the Product Acceptance Plan should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Product Acceptance Plan.]

1.1 Purpose

[Specify the purpose of this Product Acceptance Plan.]

1.2 Scope

[A brief description of the scope of this Product Acceptance Plan; what Project(s) it is associated with, and anything else that is affected or influenced by this document.]

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Product Acceptance Plan. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Product Acceptance Plan.á Each document should be identified by title, report number (if applicable), date, and publishing organization.á Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.]

1.5 Overview

[This subsection should describe what the rest of the Product Acceptance Plan contains and explain how the document is organized.]

2. Responsibilities

[Explicitly identify the responsibilities of both the customer and the development team in preparing and performing the product acceptance activities.]

3. Product Acceptance Tasks

3.1 Product Acceptance Criteria

[Identify the objective criteria for determining acceptability of the deliverable artifacts from this project.á These criteria should be formally agreed by the customer and the development team.]

3.2 Physical Configuration Audit

[Identify and list here the artifacts that are to be delivered to and accepted by the customer resulting from the work on this project.]

3.3 Functional Configuration Audit

[For each artifact identified in the Physical Configuration Audit, identify the evaluation method(s) and the level of detail that will be used to determine if it meets the product acceptance criteria.

Methods can include software execution testing, product demonstration, documentation reviews, etc.]

3.4 Schedule

[A schedule indicating the start and end times for each of the product acceptance tasks, including preparation and set-up activities.]

4. Resource Requirements

4.1 Hardware Requirements

[For example, hardware items, interfacing equipment, firmware items.]

4.2 Software Requirements

[For example, operating systems, compilers, test drivers, test data generators.]

4.3 Documentation requirements

[For example, test documentation, technical references.]

4.4 Personnel Requirements

[For example, development team members, customer representatives, third-party party authorities.]

4.5 Test Data Requirements

[For example, size, type, and composition of data to support acceptance tests.]

4.6 Other Requirements

[For example, special equipment.]

5. Problem Resolution and Corrective Action

[This section describes the procedures for reporting and handling problems identified during the Product Acceptance activities.á Usually this is addressed by enclosing the Problem Resolution Plan artifact by reference.]

6. Product Acceptance Environment

[Describe the plans for setting up the product acceptance environment.]

7. Identification of Required Artifact Evaluations

[Based on the Functional Configuration Audit description, identify each individual artifact evaluation that will be carried out.á For each one, list the type of evaluation (test, review etc), and its objective(s)

Note: A Test Case artifact will be prepared for each test identified here.]

8. Tools, Techniques and Methodologies

[A list of any specific tools, techniques, and methodologies that are to be used when performing the Product Acceptance activities.]